1. Field of the Invention
This invention relates generally to communication systems, and, more particularly, to wireless communication systems.
2. Description of the Related Art
Wireless communication systems provide wireless connectivity to one or more mobile units over one or more air interfaces. Mobile units may also be referred to using terms such as user equipment, mobile terminal, access terminal, and the like. Exemplary mobile units include cellular telephones, personal data assistants, smart phones, text messaging devices, wireless network interface cards, laptop computers, desktop computers, and the like. Wireless connectivity may be provided using one or more wireless communication protocols. Exemplary wireless communication protocols include the Universal Mobile Telecommunication System (UMTS) protocol, the Global System for Mobile communication (GSM) protocol, Code Division Multiple Access (CDMA, CDMA 2000) protocols, the Bluetooth protocol, the IEEE 802 protocols, and the like.
The network environment of a wireless communication system typically depends on the wireless communication protocol implemented by the system. For example, a standard UMTS network environment includes one or more Gateway General Packet Radio Service (GPRS) Support Nodes (GGSNs), Serving GPRS Support Nodes (SGSNs), Radio Network Controllers (RNCs) and base stations (also referred to as Node-Bs). The GGSNs and SGSNs, are typically considered part of a wireless core network. The RNC and the Node-Bs typically form a Radio Access Network (RAN). The GGSN, SGSN and part of the RNC provide IP tunneling functionality and macro-mobility, and the RNCs and Node-Bs provide for wireless transmission and reception functionality and micro-mobility functionality.
In operation, the GGSN and SGSN may shape and/or tunnel packets received from an Internet and provide the shaped/tunneled traffic to the RNC. The RNC may forward the traffic (e.g., in the form of transport blocks) to the Node-Bs, which provide wireless channel communication with one or more mobile units. If a wireless channel needs to be relocated, the RNC may instruct other Node-Bs in the vicinity of the mobile unit to host the wireless radio channel. If the mobile unit is at or near the edge of the area served by the RNC, wireless channels can be relocated from the current RNC to another RNC, but this requires the SGSN to re-route traffic from the current RNC to the other RNC. This rerouting may involve changing SGSNs as well. The point of attachment to the internet, i.e. the GGSN, does not change during these handoffs. The mobile unit remains connected to the same GGSN for as long as the mobile unit hangs on to an IP address.
Wireless communication networks that operate according to Mobile-IP utilize a different network environment. For example, a base station router (BSR) network that operates according to Mobile-IP may include a Mobile-IP Home Agent (HA) and one or more BSR network elements. The HA provides macro-mobility support in collaboration with a Foreign Agent (FA) embedded inside the BSR. This FA is further tightly integrated with the micro-mobility procedures inside the BSR. For example, whenever a radio channel is relocated from one BSR to another BSR by way of the micro-mobility procedure, the HA is notified of this change by a Mobile IP registration procedure, possibly initiated by Proxy Mobile IP functionality inside the BSR. This registration procedure registers a new Mobile IP care-of address inside the HA, which coincides with the BSR that hosts the wireless radio channel. In some embodiments, the FA may include Proxy Mobile IP functionality that may be integrated in the BSR to support a Mobile-IP-unaware mobile unit. A typical deployment scenario for a BSR is to host the Mobile IP HA in a well-networked location, while the BSRs themselves are located in the field, typically connected by slow last-mile copper links. Newly deployed BSRs may be used to replace current wireless base stations and a large fraction of these base stations are still connected by E1/T1s. In some cases, the BSRs may be wired up by cable modems, DSL links, and other slow media.
The rate at which data is transmitted between the network elements may be determined according to the appropriate wireless communication protocol. Within a cellular UMTS system, the GGSN and SGSN can shape the IP traffic as it travels down from an internet into the RAN. The RAN may determine an outflow rate for each mobile unit and provide the outflow rate to the GGSN during call setup for the mobile unit. The GGSN may then shape downlink traffic to the RAN based on the outflow rate determined during call setup. Although the outflow rate from the RAN to the mobile unit may vary during the call, the GGSN typically continues to shape the downlink traffic to the RAN based on the outflow rate determined during call set up, e.g., rate control in a UMTS system is not dynamic.
The current Mobile IP HA does not support any quality of service (QoS) or traffic shaping functionality. This means that all data that arrives in the HA is forwarded immediately to the BSR, regardless of the outflow rate that may be used to transmit data to the mobile unit over the air interface. Consequently, IP queues may build up in the BSR when the data outflow rate out of the BSR, i.e. over the wireless radio channel, is less than the inflow rate into the BSR. Large queues may cause the Transmission Control Protocol (TCP) to perform in an unexpected and/or undesirable manner. For example, when multiple TCP sessions are tunneled through the same wireless channel to the mobile, the combined effects of a large queue inside the BSR (or RNC for that matter) and Radio Link Control (RLC) link-layer retransmissions may cause the TCP sessions to oscillate. In addition, when a downlink packet is lost, large network buffers may lead to long recovery periods.
Large queues may also impact the performance of the wireless communication system during handoffs. For example, to perform a lossless relocation from source BSR to target BSR, all state associated with the radio channel needs to be copied from the source BSR to target BSR. This state may include the layer-2 state, such as Medium Access Control (MAC), RLC and Packet Data Convergence Protocol (PDCP) parameters. The state also includes all pending IP packets that have been received by the BSR but have not yet been transmitted over the wireless radio channel. As discussed above, the BSRs are typically connected to the backhaul link by slow links, such as last-mile copper links, E1/T1 links, cable modems, DSL links, and the like. Copying large IP queues may therefore reduce the maximum handover rate of live wireless radio channels, e.g. radio channels carrying IP traffic. If the BSR were to queue a typical maximum sized TCP congestion window of 64 KB, the handover time over a T1 would be minimally 300 ms. In other words, at most 3 handovers per second can be supported on a T1/E1-based BSR backhaul if the length of the queue inside the BSR is approximately equal to 64 KB.
To avoid TCP performance and/or handover problems, it is common practice to limit the queue lengths inside routers such as the BSR to a relatively short queue. Floyd and Jacobson [FvJ93] proposed a Random Early Drop (RED) scheme that marks and drops packets as soon as the queue length in the router exceeds a certain threshold. Brakmo, O'Malley and Peterson [BOP94] present a scheme (TCP Vegas) to enable TCP to respond gradually to variation in round-trip-delay rather than packet drops, avoiding radical rate reductions and long recovery periods. More recently, Jin, Wei, and Low [JWL04] presented a congestion control scheme particularly to deal with high-speed, high-latency TCP flows. The proposed techniques manage a queue inside the network and selectively drop IP frames from TCP/IP sessions. In a manner consistent with the end-to-end Internet architecture, they signal and indirectly control the input rate of traffic sources by assuming that the sources will detect increased delay and/or drops and reduce their rates accordingly.
The proposed techniques also assume that the queue is located immediately prior to the bottleneck resource. Thus, a queue builds immediately before the bottleneck link(s). However, the queue capacity is typically constrained to be small to minimize the amount of data transferred on handoff and keep handoff times short. Consequently, the actual bottleneck will be the channel between the BSR and the mobile unit even though the link between a home agent (HA) and a BSR is a precious resource. In the Internet setting, queue size is controlled by feedback from the endpoints. However, the round-trip time is long compared to the rate of change of the outflow rate from the bottleneck queue. The proposed techniques also assume that the HA and/or BSR will transmit data over the slow backhaul link and there is no conventional method of controlling the traffic on the valuable HA-BSR link. Uncontrolled sources (e.g. UDP traffic) can therefore flood the HA-BSR link with traffic destined to be dropped immediately on the link between the BSR and the mobile unit. Even congestion-aware sources cannot react quickly enough to changes in outflow rate, so the HA-BSR link will be used inefficiently even among TCP sources.
The outflow rate of the wireless downlink channel is not fixed but varies over time. For example, high data rate techniques such as High Speed Downlink Packet Access (HSDPA) techniques, EV-Data-(DO) techniques, and the various 802.16 techniques can schedule the downlink based on the actual wireless channel conditions to improve the efficiency of the wireless channel. For another example, the outflow rate for conventional circuit-switched technologies such as CDMA 1xRTT and UMTS R99 is not predictable because retransmissions and control message overhead may compete with regular traffic for bandwidth over the wireless radio channel.
Traffic shaping may be performed at the BSR to account for the variations in the outflow rate. However, the input rate, and therefore the queue size in the BSR, will be determined by the aggregate endpoints whose traffic travels over the BSR. If the endpoints don't react in a timely manner the (short) BSR queues will overflow, and a potentially large number of packets will be discarded. In the Internet setting, queue size is controlled by feedback from the endpoints. For example, the round-trip time between the endpoints may be long compared to the rate of change of the outflow rate from the bottleneck BSR queue, which may prevent the endpoints from responding to changes in the outflow rates, leading to discarded packets.
Furthermore, Universal Datagram Protocol (UDP) applications may be able to flood the BSR backhaul link. For example, when an application is transmitting UDP/IP traffic to a mobile client and there is no rate control available in the downlink, the UDP application can easily flood the backhaul thereby interfering with other applications, or even with the basic operation of the BSR. As discussed above, dynamic rate control is also absent in a typical 3GPP deployment.